AWSの「分散負荷テストソリューション ワークショップ」を体験したのでEC2に負荷をかけてみた
2024.07.31こんにちは、なおにしです。
AWSの「分散負荷テストソリューション ワークショップ」がとても良かったのでご紹介したいです。
はじめに
AWSでは「ビジネスおよび技術的なユースケースのための検証済みのソリューションとガイダンス」として「AWSソリューションライブラリ」が公開されています。
その中の一つに「AWS での分散負荷テスト（Distributed Load Testing on AWS：以降DLTと略）」ソリューションがあります。
今回体験したのはそのソリューションのワークショップです。
ワークショップをやってみて個人的に良かったと感じた点を挙げます。
-
分かりやすい
- 冒頭の解説のAWS構成から最初は少し複雑そうな印象を受けましたが、実際やってみると説明内容も含めて非常に分かりやすくてスムーズに進めることができました
-
見ていて面白い
- 負荷テスト実施中は以下のようにリアルタイムでリクエストの状況が表示されます
-
JMeter の入門にもなる
- ワークショップで提供されているサンプルの.jmxファイルをJMeterに読み込ませることで、どのようなシナリオをJMeterで作成してDLTと連携すれば良いか学ぶことができます
DLTの紹介記事は既に先達が公開しておりますので、こちらもご参照ください。
公式ページにある実装ガイドのドキュメントにはもちろん詳細な内容が記載されていますが、事始めとして着手するのであれば、DLTのセットアップ方法や使い方、JMeterとの連携についてはワークショップを実際にやっていただくことがベストだと思います。
また、負荷テストの考え方や計画については以下のbuilders.flashの記事「負荷テスト on AWS のすすめ」にまとめられていますので、是非ご参照ください。
DLTに関するより詳細なパラメータや検証結果等に触れた記事は末尾にリンクを記載しました。
このため本記事の意図としては、DLTの雰囲気が伝わって、負荷テストやワークショップをやってみるきっかけになれば幸いです。
前提
「そもそもAWSで負荷テストってやっていいんだっけ？」と考えられる方もいらっしゃるかと思います。
負荷テスト自体は AWS Well-Architected 内の項目「パフォーマンス効率」でも記載があり、実施すべきものという位置付けです。
一方で、実施にあたっては制限があり、その条件は以下にまとめられています。
記載内容からすると、実施を予定している負荷テストが、AWSが定義する以下2つのテストに該当していないことを確認する必要があります。
- ネットワーク負荷テスト
- DDoS シミュレーションテスト
両方のテストに該当していないことを判断するためには、実施予定の負荷テストの内容を以下の観点と照らし合わせます。
- 「ネットワーク負荷テスト」に該当しないために、以下の条件に合致していないこと
Amazon EC2 インスタンスから生成されるトラフィックが
- 全体として 1 分を越えて継続する、1 Gbps (10 億ビット/秒) または 1 Gpps (10 億パケット/秒) を超えるもの
- 不正なまたは悪意のあると見られるトラフィックが生成されるもの
- 予想されるテストのターゲット以外のエンティティ (ルーティングや共有サービスインフラストラクチャ) に対して影響を与える可能性が存在するもの
- 「DDoS シミュレーションテスト」に該当しないために、以下の条件に合致していないこと
ターゲットやインフラストラクチャに対し、以下を与えようとするもの
- 処理能力を超えたパケットや接続のフラッディング攻撃
- リフレクションや複雑さによる攻撃
- その他の大量のトラフィックを送りつけることによる打撃
上記2つのテストに該当しない負荷テストについてはAWSに対して特に申請無しで実施可能です。まとめると以下のとおりです。
| テスト種別 | テスト定義 | AWSへの申請要否 |
|---|---|---|
| (一般的な)負荷テスト | 大規模なワークロードを模擬したカスタマーユニットテストのようなタスク（ = 上記条件に合致しないもの） | 不要 |
| ネットワーク負荷テスト | 上記条件に合致するもの | 必要 |
| DDoS シミュレーションテスト | 上記条件に合致するもの | 必要 |
なお、ネットワーク負荷テストのポリシーについては以下の内容が前提になっていることにご注意ください。
このポリシーは、Amazon EC2 インスタンスから、別の Amazon EC2 インスタンス、AWS のプロパティ/サービス、外部エンドポイントなどの他のロケーションに向けて、ボリュームの大きなネットワークテストの実行を計画中のお客様に関係します。
負荷テストを実施するということは「負荷をかける側」と「負荷をかけられる側」が存在します。
以下の図(ワークショップの構成図を転載)でいうと、左側のDLT環境が「負荷をかける側」、右側のTodoアプリ環境が「負荷をかけられる側」です。
つまり、ネットワーク負荷テストのポリシーに該当するかどうかを確認すべき環境は左側のDLT環境です。
このため、例えば「負荷をかける側」としてオンプレ環境を用いて負荷テストを予定しているのであれば、前提としてネットワーク負荷テストのポリシーに該当しません。
ではオンプレ環境からであれば無制限に負荷をかけて良いのかというとそうではありません。想定する本番ワークロードを定義せずに環境がどこまで耐えられるのか確認するような負荷テストは、DDoS シミュレーションテストのポリシーに合致してポリシー違反になる可能性があります。
また、そもそもオンプレ環境からAWS環境の負荷テストを計画しても、クライアント端末の性能やネットワーク帯域などの要素がボトルネックとなり、目標とする負荷をかけられないということもあり得ます。
そこで活用できるのがDLTです。DLTであれば「負荷をかける側」としてのインフラをAWS上で容易に拡張することができ、さらに以下のように「Avg Bandwidth」の項目でテストで生成されたすべてのリクエストの平均帯域幅を参照することが可能です。
したがってDLTを活用することで、規模の小さい負荷テストから開始して、制限を超えていないことを確認しながら要件を満たす負荷がかかるまで段階的に負荷を増やしていく、というようなオペレーションを効率的に実施することができます。
やってみた
今回はEC2インスタンス(m6i.large / Amazon Linux 2023)に実際にDLTから負荷をかけてみます。構成は以下のとおり非常にシンプルです。
DLTのデプロイはワークショップ内の「2.2. DLT ソリューションのデプロイ」に従ってCloudFormationスタックを展開、ログインユーザ名やメールアドレスなどを設定します。
CloudFormationスタックの展開が進行すると、指定したメールアドレスに以下のようなメールが届きます。
CloudFormationスタックの展開が完了後、メール内のログインURLにアクセスしてユーザ名/パスワードを入力します。
DLTにログインした直後の画面が以下になります。テストを行うために[CREATE TEST]を選択します。
テストの実行設定画面は以下の1ページのみでとてもシンプルな構成になっています。今回は赤枠で囲った部分を設定しました。各項目の詳細な解説は末尾の参考サイトなどでご確認いただければと思います。設定したら右下の[RUN NOW]ボタンを押下するとテストが開始されます。
テストの実行画面に遷移します。1分ほど待ちの状態になりますが、バックエンドではECSでタスクが起動されています。ECSコンソールにアクセスするためのリンクが画面中央部に準備されているのでアクセスしてみます。
ECSのタスクが実行されると、以下のように内容を確認することができます。負荷をかけられる側のEC2にとってのアクセス元IPアドレスはこちらのパブリックIPになります。
テストが開始されてから指定した時間が経過すると画面の更新が止まるため、画面右上の[REFRESH]ボタンを押します。
以下のようにテスト実施結果のレポートが表示されます。アクセスが成功した数は「157242」となっています。
実際にEC2にログインしてアクセスログを確認してみます。
確かにステータスコード200で応答した数は一致していますが、アクセスエラーの原因はEC2ではなさそうに見えます。ECS側のリソースな気もしますが、トラブルシューティングについては割愛します。実際にDLTでの負荷テストを計画する際は、JMeterと連携して一定時間内のアクセス数を制御しながら実施することも可能です。
EC2のCPU使用率もテスト実施時のみ若干上昇していることが分かります。
まとめ
DLTを用いて負荷をかける先はAWS環境以外も可能であるため、幅広く活用できるソリューションだと感じました。本番運用を開始する前にボトルネックやエラーを特定し、安定稼動するシステムの構築のためにぜひご活用ください。
本記事がどなたかのお役に立てれば幸いです。
